A SECURITY APPROACH FOR THE STORAGE OF CREDENTIALS FOR OFFLINE USE AND AGAINST COPY PROTECTED CLEAN
专利摘要:
The present invention relates to a computer-implemented method for the secure storage of credentials for offline use and copy-protected vault content, using a server and an application on a user's device, comprising the steps of: a) said server storing said credentials, unable to decrypt said credentials themselves; b) said application that stores encrypted credentials on said device, unable to decrypt said credentials without the help of a trusted third-party application and / or said user; c) being able to distribute said credentials over different devices of said same user, using both said server and interaction of said user; d) said user provides backup data without credentials to said server to restore said credentials in the event of loss of said device; wherein the method does not require a Secure Element, but is secured using cryptographic keys and encrypted storage. In a second aspect, the present invention provides a system suitable for said computer-implemented method. In a third aspect, the present invention provides an application product suitable for said computer-implemented method. 公开号:BE1024812A9 申请号:E20165324 申请日:2016-05-09 公开日:2018-07-26 发明作者:Meester Jan De;Mulder Yoni De 申请人:Thanksys Nv;Sodexo S A Nv; IPC主号:
专利说明:
(30) Priority data: 07/05/2015 EP 15166789.6 04/05/2016 EP PCT / EP2016 / 060107 (71) Applicant (s): THANKSYS NV 3500, HASSELT Belgium SODEXO S.A. public limited company 92130, ISSY LES MOULINEAUX France (72) Inventor (s): THE MASTER Jan 2600 ANTWERP Belgium DE MULDER Yoni 2640 MORTSEL Belgium (54) A SECURITY APPROACH FOR THE STORAGE OF CREDENTIALS FOR OFFLINE USE AND AGAINST COPYING SECURE SAFE CONTENT IN DEVICES (57) The present invention relates to a computer-implemented method for the safe storage of credentials for offline use and copy-protected vault content, using a server and an application on a user's device, comprising the steps of: a) said server storing said credentials, unable to decrypt said credentials itself; b) said application that stores encrypted credentials on said device, unable to decrypt said credentials without the help of a trusting third party application and / or said user; c) be able to distribute said credentials across different devices of said same user, using both said server and interaction of said user; d) said user provides backup data without credentials to said server to restore said credentials in case of loss of said device; where the method does not require a Secure Element, but is secured using cryptographic keys and encrypted storage. In a second aspect, the present invention provides a system suitable for said computer-implemented method. In a third aspect, the present invention provides an application product suitable for said computer-implemented method. <Device> | ["Server" features Pus, Pfs _ "Memory Box Application" includes Pus Enc; p u & r prApe, <-i) (UID, Device_Id f PIN, Γα ρρ , OBID), n ·, Püa pp Ko »OWF (Deviee_ïd, Γαρρ> r s ) Kl «OWF (PIN, Device_Id, r Spp , r,) EnC (PUApp, PrS, n2) (Rs © ΓΑρβ, ΜΑΟκθ (ΓΑρρ)), n 2 © OWF (X2, ÎApp} Out-of-band channel! OSIDtxs) Loss link (UID) Ko = ÔWF (Device_îd, Γαρ Ρ , r s ) Ki = OWF (PIN, Device_Id, γδ «,, r s ) MACKi (rs) «Memory Box Application * saves (UID, Pa« v fs) «Server * saves (UID, OBID, Device_Id, Ko, Kj) Fig. i BE2016 / 5324 A security approach for storing credentials for offline use and copy-protected vault content in devices TECHNICAL AREA The invention relates to the technical field for securing credentials and copy-protected vault content in devices such as smartphones or tablets. BACKGROUND There remains a need in the art for enhanced security of a crypto graphic key in devices, particularly with regard to payment and other transaction services, especially in the case of mobile devices. The most obvious way for the latter to date is to use the embedded Secure Element (SE), eg a SIM or SD card. However, there are many Problems to establish this form of security in the ecosystem of mobile applications (apps), e.g. different operating systems, different mobile providers (service providers) and different hardware vendors. However, this high level of safety is not always necessary. A simple username and password or an embedded key is often sufficient, but this has the drawback that either the credentials must be (a) stored offline, making them relatively easy to hack, or (b) stored in the cloud, which always requires online access. Document US2009132813 describes a device and methods for providing scalable, dynamic, individualized credential services using mobile phones. The document describes a schedule to execute transactions between a user and another party, such as a merchant, in a secure environment. The entire scheme is based on the PKI (Public Key Infrastructure). The schema allows (1) to allow the user to authenticate on their device to unlock credentials, (2) to securely pass the credentials to another party, (3) to authorize the other party to the user on based on the presented credentials. The concept described in US2009132813 is limited to authentication with credentials, while the invention described in this document covers a multitude of aspects related to secure storage of sensitive BE2016 / 5324 data, as well as the use of this data as monetary value in either a real or virtual currency. In addition, the concept described in US 2009132813 is entirely dependent on the use of a PKI, while the invention described in this document is based on a more complex cryptographic solution than just PKI. Document Towards User-Friendly Credential Transfer on Open Credential Platforms by Kari Kostiainen et al. Published in Lecture Notes in Computer Science 6715 (p. 395-412, 2011, doi: 10.1007 / 978-3-642-21554-4_23) describes an open credential platform that allows a service provider to issue credentials to a hardware Trusted Execution Environment (TrEE) and transfer those credentials between the TrEEs on different mobile devices belonging to the same user using a Trusted Server. The concept described in the said document by Kari Kostiainen et al. Is dependent on specific hardware referred to as TrEE and cannot be implemented without said specific hardware, while for the invention described in this document no special type of hardware is required. Second, the concept described in the aforementioned Kari Kostiainen et al. Document is limited to transferring credentials and does not allow restoring credentials. This is in contrast to the invention described in this document, which allows credentials to be distributed to different devices belonging to the same user and allows credentials to be restored even when the user no longer owns devices. Third, the concept described in the said document by Kari Kostiainen et al. Is limited to operation that requires an online connection to a Trusted Server, while the present invention also allows offline editing. Finally, the concept described in said document by Kari Kostiainen et al. Is limited by a trust on first use approach (as mentioned in the paper), while embodiments of the present invention allow the user to use the software utility at any time install, uninstall, and reinstall that implements the method described in this document. Document Electronic Safe for Passwords Storage from Kamil Smieszek et al. Published in Przeglad Teleinformatyczny, T. 2, Nr. 3-4 (38) (pp. 3-15, 2014) describes a concept and related software utility (ie an application) that allows a user to create their own vault (called the Electronic Safe for Passwords Storage or ESPS for short) store sensitive BE2016 / 5324 data, where sensitive data is protected through the use of a hardware Trusted Platform Module (TPM) and the supported Root of Trust. The safe and the Root of Trust can be stored on removable storage media, such as a removable Flash RAM drive to make the ESPS available on other devices as well. The application consists of two components: (1) the database in which the encrypted sensitive data is stored and (2) the TPM and the supported Root of Trust in which all cryptographic keys are stored and all cryptographic operations are performed. The concept described in said document by Kamil émieszek et al. Is limited by the dependence on specific hardware (i.e. TPM), while no specific hardware is required for the present invention. The dependence on TPM further limits the applicability of the concept described in the aforementioned document from Kamil émieszek et al. Because TPM is not available as such for mobile devices. The present invention, on the other hand, can be used for both desktop and laptop computers as well as for mobile devices. Moreover, the concept described in the aforementioned document by Kamil émieszek et al. Is limited to the secure storage of sensitive data, and more specifically of authentication data. In contrast, the invention described in this document not only provides a solution to securely retrieve sensitive data offline on a device, or to store, distribute, and restore sensitive data to a device using a Trusted Server, but also provides a solution to store copy-protected vault content and to securely exchange this content peer-to-peer, ie offline, between devices. Finally, the concept described in said document by Kamil Smieszek et al. Is problematic when it comes to distributing said ESPS to other devices, because each device has its own TPM that supports a different Root of Trust. The present invention, on the other hand, fully supports distribution across various devices. Document US8959579B2 describes a method of providing secure containers or data vaults for data from one or more managed applications, which means that reads or writes from the managed application are intercepted when the application is run on a mobile device. In some embodiments, each managed application can be assigned its own data vault and / or a shared data vault that is accessible to at least one other managed application. When the managed application is running, calls to access the data can be intercepted and diverted to the secure one BE2016 / 5324 containers. Data stored in a secure container can be encrypted according to a policy. Other aspects involve removing data from a secure container, such as through selective deletion of data associated with a managed application. Further aspects include configuring and creating secure containers, retrieving important information required to encrypt / decrypt the data stored in the secure containers, and publishing the managed applications, policy information and key information for the download to a mobile device. Document W02013040605 describes a computer-implemented method for initiating a contactless payment transaction on a mobile computing device, which includes: contactless payment transactions are initiated through single input activation of the Secure Element and contactless communication system from a mobile device; - activation of the Secure Element and the contactless communication system is linked to the activation status of the mobile device screen; activation of the Secure Element can be further linked to the activation status of an electronic wallet application. When activation of the electronic wallet is required, one-click activation of the electronic wallet and Secure Element is provided. Document W02005067402 describes a mobile terminal for certification, and an electronic transaction system and method using the same, downloading a certificate to a mobile terminal from a certification authority. In a wired electronic transaction, a user's transaction history is provided to a service server's mobile terminal or a user's transaction terminal, and the mobile terminal digitally signs the transaction history using a stored digital certificate and provides the digitally signed transaction history to the service server or the transaction terminal so that the service server can eventually receive the digitally signed transaction history. The service server arranges the transaction with the user according to the digitally signed transaction history and provides a service to the user. The certificate is also included in the offline transaction BE2016 / 5324 stored in the mobile terminal supplied to a system to thereby conduct stable transactions based on the certificate. The aforementioned documents do not seem an elegant and lightweight application for the combination of secure local storage of an offline password, online transaction security using a symmetric or asymmetric key, or peer-to-peer transaction security using an asymmetric key pair, without using a Secure Element. The present invention aims to solve at least some of the aforementioned Problems. The object of the invention is to provide a solution for this which lies between storing the credentials (a) offline or (b) in the cloud. The present invention does not provide the high level of security that hardware can provide for high-end applications such as payment methods, but at the same time the invention does significantly increase the level of security compared to the simpler classic username / password model. The present invention can also be implemented on a hardware Secure Element and therefore can be critical in a migration process from non-hardware to hardware security. SUMMARY OF THE INVENTION In a first aspect, the invention relates to a computer-implemented method of securely storing credentials for offline use and copy-protected vault content, using a server and an application on a user's device, comprising the following steps of: a) said server storing said credentials unable to decrypt said credentials itself; b) said application that stores encrypted credentials on said device, unable to decrypt said credentials without the help of a trusting third party application and / or said user; c) be able to distribute said credentials across different devices of said same user, using both said server and interaction of said user; d) said user provides backup data without credentials to said server to restore said credentials in case of loss of said device; B E2016 / 5324 where the method does not require a Secure Element, but is secured using cryptographic keys and encrypted storage. In a further aspect of the present invention, this includes a Key Unlocking Code (e.g., a PIN, passphrase ...) from said user that optionally protects said credentials and said copy-protected vault content, said server and said application holding the Key Do not save the unlocking code of said user. In a further aspect, said application stores said credentials or said copy-protected vault content of said user on said device in an encrypted form, unable to decrypt said credentials or said copy-protected vault content without the help of a third party trusting application and / or said user. In a further aspect, said server restores said credentials on a new device of said same user, using backup data without said credentials provided by said user and without interaction with said other device of said user. In a further aspect, said server is unable to distribute said copy-protected vault content to various devices of said same user or to restore said copy-protected vault content to a new device of said same user to prevent copying or cloning. In a further aspect, said copy-protected vault content is transferred from said first device of said first user to a second device of said first user and / or said copy-protected vault content is transferred from said first device of said first user to a third device of a second user without connecting to said server. In a further aspect, the present invention provides a system suitable for a computer-implemented method of securely storing credentials for offline and / or online use and copy-protected vault content, which includes a processing unit configured to execute the method as described above. B E2016 / 5324 In a further aspect, the present invention provides an application product suitable for a computer-implemented method of securely storing credentials for offline use and copy-protected vault content, comprising at least one computer-accessible medium on which computer-accessible program code parts are stored, which instructions for implementing the computer-implemented method as described above. FIGURES Figure 1 shows a first embodiment of the present invention. Figure 2 shows a first embodiment of the present invention. Figure 3 shows a first embodiment of the present invention. Figure 4 shows a second embodiment of the present invention. Figure 5 shows a second embodiment of the present invention. Figure 6 shows a second embodiment of the present invention. DETAILED DESCRIPTION OF THE INVENTION Unless otherwise defined, all terms used in the description of the invention, including technical and scientific terms, have the meaning generally understood by one skilled in the art to which this invention belongs. As further guidance, term definitions have been included for a better understanding of the teachings of the present invention. As used herein, the following terms have the following meanings: One, it and the as used herein refer to both singular and plural referents unless the context clearly indicates otherwise. For example, a compartment refers to one or more than one compartment. Include, include and include and include as used herein are synonyms of contain, contain, contain 'or consist of, consist of, consist of and are inclusive or open terms that specify the presence of what follows, e.g. component and the presence do not prevent or exclude additional components, features, elements, members and steps known or described in the art which are not known in the art. BE2016 / 5324 The term credential refers to information that the user or application can use for the verification and security of transactions with a particular provider. Examples of credentials are PIN, passwords, symmetric keys, asymmetric keys, tokens, certificates, signatures and biometric data. Credentials can be used online and offline. The term vault content refers to data that is valuable to the user for a particular service and must be protected against copying. Examples of safe contents include meal vouchers. gift certificates, tickets, coupons, software package license keys, signatures, certificates, cryptographic keys. The term device refers to a small computer device, usually small enough to hold in your hand (which is why it is also commonly known as a handheld computer or handheld for short) with a touch input display and / or a miniature keyboard, e.g. a smartphone or tablet computer. A device has an operating system (OS) and can run various types of application software, known as apps. The term device ID (DID) refers to an identifier of the device. The device ID may include a hardware fingerprint and / or other device-specific information. The term point of service (POS) refers to where the transaction is completed. It is the point at which a customer interacts with a merchant in exchange for goods or services. The term memory box refers to a specific part of the encrypted storage of a computer-accessible medium, eg the internal memory of a device. In this document, the term memory box application refers to any software application present on the client side that implements the method described in this document. It should therefore not be construed as limiting the invention described in this document to one or more specific embodiments. The term Secure Element refers to a fraud-resistant platform (usually a secure single-chip microcontroller) on which applications and their confidential and cryptographic data (e.g. key management) can be safely hosted in BE2016 / 5324 complies with the rules and security requirements established by a range of well-identified trusted entities. The term server in this document refers to a server that provides online network service that allows applications to store, distribute, and retrieve the credentials. The term key refers to a piece of information (a parameter) that determines the functional output of a cryptographic algorithm or encryption. Without a key, the algorithm would yield no useful result. In encryption, a key specifies the special transformation from readable text to encrypted text or vice versa during decryption. Keys are also used in other cryptographic algorithms, such as digital signature schemes and Message Authentication Codes. To avoid guessing a key, keys really need to be randomly generated and have enough entropy (chaos). The problem of safe generation of truly random keys is difficult and has been addressed in many ways by different cryptographic systems. The term public key cryptography, also known as asymmetric cryptography, refers to a class of cryptographic algorithms that require two different keys, one of which is secret (or private) and one of which is public. Although different, the two parts of this key pair are mathematically linked. The public key is used to encrypt human-readable text or verify a digital signature; while the private key is used to decrypt encrypted text or create a digital signature. The term asymmetric stems from using different keys to perform these opposite functions, each of which is the inverse of the others - as opposed to conventional (symmetrical) cryptography based on the same key to perform both. The term symmetric key cryptography refers to a class of cryptographic algorithms that use the same cryptographic keys for both readable text encryption and encrypted text decryption. The keys can be identical or a simple transformation may be needed between the two keys. In practice, the keys represent a shared secret (e.g., a password, passphrase, large number, or an array of randomly selected bytes) between two or more parties that can be used to maintain a link to personal information. BE2016 / 5324 The term digital certificate refers to an electronic document generated to prove ownership of a public key in the context of public key cryptography. The term client verification refers to the secure identification of a client with respect to a system or third party, where the identification is not limited to a mere declaration of the client's identity by the client, but also includes a means of verifying that the client identification is bona fide. The term out-of-band authentication refers to the principle in cryptography to authenticate using a connection or channel that is separate from the primary connection or channel for authentication. This concerns the broader concept of multiple verification, where a client is considered to be verified against a system only after some complementary evidence of identity has been provided by the client. The term plaintext in cryptography refers to information that a sender wants to convey to a recipient. Cleartext is often used as a synonym. Plaintext refers to the operation of cryptographic algorithms, usually encryption algorithms, and is the input with which the algorithms work. Cleartext, on the other hand, refers to data that is sent or stored unencrypted (ie 'in the οΙεβΓ 7 ). The term OWF in computing refers to a one-way function, i.e. a function that is easy to calculate for any input, but difficult to reverse due to the mapping of any input. Here it is easy and difficult to understand in the sense of computational complexity theory, in particular the theory of polynomial time problems. Not being one-to-one is not considered sufficient for a job to be called a one-way job. The term KUC refers to a Key Unlocking Code and is provided by the user during the process of deriving a key. Examples of a KUC are a numeric code (PIN), an alphanumeric password or passphrase or a biometric aspect, such as a fingerprint. The term KDF in computing refers to a Key Derivation Function, ie a one-way function (OWF) that intentionally consumes a specified time and optional memory and is also used to calculate a stronger cryptographic key from a weak cryptographic key such as a user's KUC . A KDF BE2016 / 5324 is usually used as a countermeasure against dictionary attacks or brute force attacks. The term MAC in cryptography refers to a Message Authentication Code that provides data integrity and authenticity based on the use of a symmetric key. A MAC is usually used to prove ownership of a symmetric key, or to provide data integrity and authenticity. The term nonce in cryptography refers to a random number that is used only once in a cryptographic communication. The term salt in cryptography refers to arbitrary data used as an additional input for a one-way function that hashed a password or passphrase. This is related to the terms salts and salts throughout this document. The term one-time code (OTC) refers to a randomly generated code that can be used only once. Such codes can be used, for example, for user authentication. The term obfuscation in the domain of software development refers to deliberately creating obfuscated code, i.e. source or machine code, that is difficult for people to understand. Programmers can intentionally darken code to hide the target (security through obscurity) or its logic to prevent manipulation and discourage reverse engineering. The term user ID (UID) is used as a unique identifier of the user. In a preferred embodiment, this UID includes a randomly generated number and / or the user's email address and / or the user's phone number. The term storage server refers to an online service where certain content can only be retrieved safely by the user. An email server can be considered a storage server, the said content being included in an email sent to the email address of the said user. A server belonging to a third party service can also be considered as a storage server, where said content is only available to said user after proper verification of said B E2016 / 5324 third party service. A protected file server can also be considered a storage server, where the said content is included in a saved file. The term memory box application refers to the application running in the device that makes the cryptographic service available to third-party trusting applications that can retrieve data from the memory box. The term third party application refers to a trusting application that uses the memory box application. The term protocol ID (PID) is used as the unique identifier of each protocol. This prevents edited replay attacks where a protocol A message is replayed for protocol B. The term counter (ctr) is an increment-only number that is shared and synchronized between the memory box application and the server and is used as a countermeasure against replay attacks. The computer-implemented method described in this document includes an application on a user's device as well as a server. The said device, e.g. a smartphone, tablet, desktop computer or laptop computer, is capable of storing credentials and copy-protected vault content. Said server helps said application initialize itself and store, restore, distribute, access or issue said credentials. In an embodiment in which the method described in this document is implemented in a software application, referred to hereinafter as a memory box application, the initialization of said application may include the following aspects. A first aspect is downloading the application to a user's device. A second aspect is the actual initialization. During this initialization, two symmetric keys KO and K1 are initialized and stored on the server side. On the application side: KO can be calculated on demand (i.e. if needed) by the memory box application without a KUC from said user, but with the user ID, device ID and any randomness stored in the memory box application BE2016 / 5324 Kl can be computed by the memory box application on demand (i.e., if needed) provided that a KUC is provided by said user, and the user ID, device ID and any randomness stored in the memory box application This means that the KO and Kl keys are never stored as such in the device and therefore not in the memory box application or in the application of third parties. Here, the purpose of the symmetric keys KO and Kl is to securely store credentials or vault contents, which may or may not require a user-provided KUC. In a preferred embodiment of the invention, the user must provide a storage ID (SID, e.g., his email address) through which the user accesses the storage server and an out-of-band identifier (OBID, e.g., his mobile phone number) during the initialization of the memory box application. In a preferred embodiment of the invention, said SID and said OBID of said user are tied together, meaning that said same user must use said same SID and said same OBID to initialize a memory box application on another device. In a preferred embodiment of the invention, said user's SID is verified during initialization to ensure that said user is the rightful owner of said SID. For example, this verification can be done by sending an activation email with an activation link to the email address provided by the user, authentication being accomplished only after the activation link is opened. In a preferred embodiment of the invention, an Out-Of-Band (OOB) channel is used for additional (i.e., two-factor) user authentication. In a preferred embodiment of the invention, the Out-Of-Band channel takes the form of an SMS and the verification takes the form of sending a verification code to Out-Of-Band-Identifier (OBID), ie the mobile phone number of named user. This also assures the server that said user is the rightful owner of said mobile phone number. In a preferred embodiment of the invention, a storage server is used to store the portion of the data used for restoring or distributing credentials afterwards. B E2016 / 5324 In a preferred embodiment of the invention, a third party application can retrieve only the sensitive data from said memory box through the memory box application, which requires KO or K1 to be reconstructed depending on which key was used to protect the stored sensitive data. In a preferred embodiment of the invention, said key is dynamically generated using user ID, device ID, some arbitrariness and optionally a KUC code for the user, the KUC code for the user never being stored in said device or on the server. In a preferred embodiment of the invention, the device ID is randomized by the memory box application to prevent replay attacks and also to prevent an attacker from simply guessing the randomized device ID. In a preferred embodiment of the invention, more than two symmetric keys can be initialized. Keys KO and Ki can be initialized, where KO is as described above, but each Ki with 1 = 1,2,3. is linked to another KUCi of said user. This allows initialization of the memory box application using more than one user-provided KUC (eg, a numeric PIN and an alphanumeric passphrase). In a preferred embodiment of the invention, said memory box application initialized with more than two symmetric keys allows the secure storage of credentials and vault contents under the protection of different user-provided KUCs, each KUC being able to achieve a lower or higher level of security. The choice of said symmetric key and said coupled KUC may depend on the sensitivity of the stored data. In a preferred embodiment of the invention, the server provides the memory box application with an asymmetric key pair for the client and the associated certificate during initialization with which client authentication can be performed during all future communications with said server. In a more preferred embodiment of the invention, the serial number of said client certificate depends on the user ID and device ID. BE2016 / 5324 In a preferred embodiment of the invention, the memory box application, once initialized, can be used by third party applications to store various credentials and vault contents. In a preferred embodiment of the invention, upon initialization of a memory box application implementing the method described in this document, the server provides the user with a one-time code to deregister said initialized memory box application and a set of one-time codes with which the user can have it verified when executing protocols via a web portal. In a preferred embodiment of the invention, a storage server is used to store said one-time codes. In the present invention, credential storage is intended to be used by third-party applications that require secure storage for their passwords, symmetric keys, asymmetric key pairs, tokens, biometric data, certificates, etc. The main focus in this case is to ensure that the credentials are stored securely when applications don't need them. The memory box application and associated server store only part of the elements needed to reconstruct a credential. The other part is handled by the third party application that wants access to the credential. This part is also supposed to be saved by the user for backup purposes. Neither the server nor the memory box application stores this part, so they cannot decrypt the stored credentials themselves. This means that once a credential has been properly stored, the memory box application and the server can retrieve it only with the cooperation of the user or the third party application for which the credential was stored. In addition, if the credential is protected under K1, the user must provide his KUC to restore the credential locally in the memory box application. In one embodiment of the invention, protocols are provided to deregister an initialized memory box application, change the user's SID, change the user's OBID, change the user's KUC, reset the user and request a new list of one-time user verification codes. In one embodiment of the invention, protocols are provided to remove credentials, whether common or single device only, to distribute / restore credentials across different devices (with the cooperation of the BE2016 / 5324 user) and request an update regarding the credentials stored on a user's device. In an alternative embodiment of the invention, protocols are provided that can be executed from a web portal instead of the memory box application. These protocols support deregistering an initialized memory box application, changing the user's SID, changing the user's OBID, and requesting a new list of one-time user authentication codes. Preferably, the user should provide a one-time verification code when executing protocols from a web portal. In a preferred embodiment of the invention, server-side credentials are reconstructed jointly by said server and said user of said application. In a preferred embodiment of the invention, application-side credentials are reconstructed jointly by said memory box application and said third-party trusting application. In a more preferred embodiment of the invention, said user must additionally provide a KUC code. In a preferred embodiment of the invention, a copy of said application is instantiated with one or more service-specific identities controlled by the service owner and with which vault content can be stored. In a preferred embodiment of the invention, said service-specific identities are implemented with a service-specific Public Key Infrastructure (PKI). In a preferred embodiment of the invention, said instance of use may be used to securely store vault contents. In a preferred embodiment of the invention, the memory box application is in the form of a software library or libraries. In a particularly preferred embodiment, the software libraries used include libraries suitable for obfuscation purposes. BE2016 / 5324 In a particularly preferred embodiment, the used Software Libraries are embedded in a Software Development Kit (SDK) that provides an interface similar to that of a hardware Secure Element. In a particularly preferred embodiment, said Software libraries comprise libraries suitable for symmetric key cryptography purposes. In a particularly preferred embodiment, said Software libraries comprise libraries suitable for asymmetric key cryptography purposes. In a preferred embodiment of the invention, said software library is available in various operating systems. In a preferred embodiment of the invention, said software library uses a Secure Element as said memory box. In a preferred embodiment of the invention, the server uses a security module that stores cryptographic keys and handles all cryptographic operations. In a preferred embodiment of the invention, said security module is either implemented in hardware or software. In a preferred embodiment of the invention, data sent from the memory box application to the server is massaged as metadata or confidential data, whereby metadata must be known to said server while confidential data need only be known to said security module of said server. In a preferred embodiment of the invention, the confidential data is also specifically encrypted for said security module of said server using asymmetric key cryptography. In a preferred embodiment of the invention, security breaches (hacking) in said memory box are prevented from eavesdropping, replay attacks, man-in-the-middle attacks, denial-of-service attacks, dictionary attacks or brute-force attacks, memory-reading malware and memory writing malware. In a more preferred embodiment, a dictionary attack or brute force attack to retrieve said KUC is prevented by programming a one-way function using an especially time and optional memory consuming algorithm such as a KDF. BE2016 / 5324 In a more preferred embodiment, an offline dictionary attack or brute force attack to retrieve said KUC is prevented by making the KDF exponentially slow depending on the number of times a KUC was entered within a given time slider window. In a more preferred embodiment, an online dictionary attack or brute force attack to retrieve said KUC is prevented by the server by locking a device on which the memory box application is installed from the moment said server detects an incorrect KUC that is a certain number of consecutive provided by the user. In a more preferred embodiment, malware attempting to read into said memory box is stopped by encrypting all credentials under KO and Kl, requiring knowledge of user ID, device ID, hardware fingerprint, any arbitrariness, optional KUC and the obfuscated algorithm of the one-way function (KDF). In a more preferred embodiment, malware trying to write in the memory box is stopped by not storing said KO or Kl except in the server. In a preferred embodiment, ie for certain uses of use cases, the protected content is not merely a credential but is vault content, ie information representing value, including movie tickets, meal vouchers and other coupons, e.g. in the form of a certificate, and the like Information allows the memory box application to act as a secure vault that only releases valuable information to other recognized memory box applications after they have been identified. This ensures that said vault content cannot be freely copied. In a preferred embodiment, a service-specific vault can be initiated by the memory box application for any service for which vault content is to be stored, where: Each service owner receives an asymmetric master key pair that identifies them, generates vault contents, and identifies service-specific instances of memory box applications. The server generates a unique asymmetric key pair with a certificate (issued by the service owner with its master key pair) for each instance of the memory box application and for each service, and BE2016 / 5324 remotely loads into the instance of the registered memory box application. This key pair and certificate allows any memory box application to identify other instances of the memory box application that have been activated for the same service so that vault content can be transferred. Vault content consists of metadata indicating what the content is worth (eg 7 EUR in meal vouchers), and a unique signature from the service owner for the metadata and any arbitrariness that gives the metadata real value. The metadata is freely accessible as it is stored legibly, e.g. for performance reasons (e.g. listing all available meal vouchers), while the signature (for the metadata) must be accessed through the memory box application and can therefore only be revealed (transferred) to others recognized service-specific vaults in memory boxes, even for the same service. Transferring content to other memory box vaults can be done offline. Vault content can also be spent at points-of-service (POS). This can be done online (i.e., the POS is connected to the back end of the service owner and / or the back end of the memory box application) or offline (i.e., without an online connection except periodically forwarding offline stored data for clearing). In a preferred embodiment of the invention, said vault content, without interaction from said server, is transferred from one service-specific vault to another identified service-specific vault, e.g. the offline transfer of a meal voucher from one device to another. In a preferred embodiment of the invention, different types of said vault contents coexist within the memory box application, but are isolated from each other. In a preferred embodiment of the invention, retrieving said vault contents from the memory box via the memory box application requires user interaction, i.e. the user must provide his KUC. In a preferred embodiment of the invention, said vault content is immediately deleted by the memory box application once it has been issued, transferred or spent and cannot be restored (i.e. said server B E2016 / 5324 will delete the content once it has been issued) and will be securely stored in up to one of the aforementioned service-specific safes to prevent copying. In a preferred embodiment of the invention, said vault content may be spent at a Point of Service (POS), said device being offline and said POS being either offline or online. In a preferred embodiment of the invention, said service-specific vault prevents or supports double use of said vault content, if necessary. In a preferred embodiment of the invention, said computer-implemented method for securely storing said credentials for offline and / or online use and said copy-protected vault content, said storage and said services, are implemented in the Secure Element of a device. In a preferred embodiment of the invention, said computer-implemented method for securely storing said credentials for offline and / or online use and said copy-protected vault content, said storage and said services are implemented in the Secure Element of a smart card. In a second aspect, the invention provides a system suitable for a computer-implemented method of securely storing credentials for offline and / or online use and copy-protected vault content, which includes a processing unit configured to implement the method as described above. In a third aspect, the invention provides an application product suitable for a computer-implemented method of securely storing credentials for offline and / or online use and copy-protected vault content, comprising at least one computer-accessible medium on which computer-accessible program code parts stored, which include instructions for executing the computer-implemented method as described above. As described in this document, a software application that implements the method described in this document acts as a secure container with some additional functionality. However, in a preferred embodiment, said application does not provide the interface through which the content can be presented and managed (e.g. meal vouchers). In a further aspect of the present invention, it is possible B E2016 / 5324 a second additional application provides the interfaces with a first application to support e.g. meal vouchers, the first application implementing the method described in this document but relying on said second application to provide the user e.g. a graphical user interface ( GUI), which, for example, adequately presents meal vouchers and provides a communication channel to a point-of-service (POS) or between different users. A first embodiment of the present invention includes steps (1) memory box initialization, (2) application initialization initialization and (3) use application credentials, as further described below: 1. Initialization memory box (see fig. 1) 1.1. Application in App Store An uninitialized memory box application contains the public key Pu_S. Obfuscation is used to store this public key within the application software and bind it to the application so that a hacker cannot easily replace it to build a rogue application. The server contains both this public key Pu_S and the associated private key Pr_S. 1.2. Installation of the application in the device During personalization of the memory box application, a temporary key pair (public key Pu_App, private key Pr_App), a random r_App and a nonce ni are generated. The user will be asked to enter his profile including a valid unique identification UID (eg email address) and optionally a valid out-of-band identification OBID (eg mobile phone number). The user is asked to select a PIN to be used as the KUC. The UID, Device_ID, PIN, r_App and optional OBID are sent to the server, encrypted under public key Pu_S, verified with the private key Pr_App and saled with nonce ni. Nonce ni and public key Pu_App are sent to the server readable. BE2016 / 5324 1.3. Server-side decryption The server decrypts the information received from the memory box application. 1.4. Dynamic key generation The server generates a nonce n2 and a random r_S. The server generates keys KO and Kl: KO is generated using an OWF using Device_ID, r_App and r_S K1 is generated using an OWF using PIN, Device_ID, r_App and r_S Protections are implemented to prevent dictionary attacks and brute force attacks, eg by implementing OWF as a time consuming algorithm. 1.5. Transmission of r_S by the server The server prepares a data set containing r_S XOR'ed (i.e. encrypted using a bitwise XOR operator) with r_App and a MAC calculated for r_App using Kl. The server sends this data containing r_S encrypted under Pu_App verified with the private key Pr_S saled with nonce n2. 1.6. Transmission of nonce n2 by the server The server can send nonce n2 readable to the memory box application. However, in case there is an out-of-band channel (eg SMS), the server can send the nonce n2 cryptographically modified with another nonce x2, which is sent via this out-of-band channel (eg SMS) ). Sending the nonce x2 through a different channel increases security, although it can still be intercepted by the network or a rogue application. However, it does have the advantage that it also brings additional confidence in identification because the user has entered a correct OBID (eg mobile phone number). 1.7. Verification of UID The server performs a process to verify that the UID is authentic and belongs to the user. In a preferred embodiment, the UID is an email address and this process takes the form of an BE2016 / 5324 verification link sent via email to the user's email address. 1.8. Dynamic key derivation by the memory box application The memory box application derives r_S from the information received from the server. The memory box application derives the dynamic keys: KO is derived using the OWF using Device_ID, r_App and r_S Kl is derived using the OWF using PIN, Device_ID, r_App and r_S Obfuscation is used in the implementation of the OWF in the memory box application. 1.9. Confirmation The memory box application generates a MAC for r_S using Kl and sends it to the server as proof that the keys were correctly derived. 1.10. Storage and deletion by the memory box application The memory box application stores UID, r_S and r_App. The memory box application removes PIN, Pu_App, Pr_App and nonces. 1.11. Storage by server After checking the authentication link and the MAC, the server stores UID, OBID, Device_ID, KO and Kl. The server removes r_S, r_App and nonces. 2. Initialization of application credentials (see fig. 2) 2.1. preface The memory box application can be used by a third party application that wants to store credentials (passwords, keys, etc.) in a mobile application for both offline and online applications. In most cases, these credentials will be initialized during installation, but of course this is not a must. To store credentials in the memory box, they must be available on the server side. The type of credential and how these credentials are generated or chosen is beyond the scope of BE2016 / 5324 the memory box concept. Here are some non-limiting options: An asymmetric key pair generated by a third-party application A password entered in the device A random symmetric key generated by a third-party application Such a credential Cred is identified by a unique identification CID. 2.2. Storage To store the credentials in the memory box, the following applies: The memory box application generates a temporary key pair (public key Pu_App, private key Pr_App), a random s_App and a nonce en. - The App derives KO or Kl from r_S and r_App, which were stored during initialization of the memory box for the particular UID (see step 1 and fig. 1). In the case of Kl, the user must enter a PIN. UID, Device_ID, CID, s_App and Cred are sent to the server, encrypted under public key Pu_S, verified with private key Pr_App, and saled with nonce ie Nonce ni and public key Pu_App are sent to the server readable. The encrypted data also contains a Message Authentication Code that uses Kl. The server decrypts the data and generates a random s_S. The server retrieves the stored KO or Kl using Device_ID and UID. The server generates a nonce n2 and a random s_S. - Credential Cred is encrypted using KO or Kl salts with a value m derived from s_App and s_S. The encrypted Cred along with its identification CID and s_S are encrypted under public key Pu_App, verified with the private key Pr_S, saled with nonce n2 and sent to the memory box application. Nonce n2 is readable sent to the memory box application. B E2016 / 5324 The identification CID and s_App is sent to the storage server, e.g. in the form of an email to the email address corresponding to UID. The data CID and s_App can be retrieved later from the storage server to ensure a full recovery or initialization. The memory box application decrypts the data and stores the encrypted credential along with the CID and s_S in the memory box. The third subject application stores CID and s_App in the application memory The server stores Device_ID, UID, CID, s_S and the encrypted credential under KO or Kl, saved with m. The server can optionally push the encrypted credential to all devices registered under the same UID (email address), using the corresponding KO or Kl. 3. Use application credentials (see fig. 3) 3.1. preface The memory box is a concept to store the credentials in the mobile application in a more secure way. How these credentials are used is beyond the scope of this invention. It is up to the application developer to decide whether these credentials are used online and / or offline and whether they are used with or without a PIN. This section on the use of application credentials therefore only focuses on how to retrieve the credential legibly. 3.2. to pick up To retrieve the credentials stored in the memory box, the following applies: If the credential requires a PIN entry to be used in the device, the user is prompted to enter the PIN. The PIN cannot be verified in the device, but entering an incorrect PIN results in an incorrect credential being retrieved. It is up to the application to see how the user gets feedback. B E2016 / 5324 The third-party application retrieves s_App using the credential identifier CID The memory box application retrieves stored s_S using CID and the associated stored credential, encrypted under either KO or Kl, saled with m. The memory box application retrieves the stored r_App and r_S using UID The memory box application derives KO or Kl using Device_ID, r_App and r_S. In the case of Kl, the user must have entered the PIN. The memory box application derives m from s_App and s_S The memory box application decrypts the stored credential using KO or Kl and sait m. The credential Cred is returned legibly to the application of third parties. The application developer should be aware that certain precautions should be observed when defining the credential. For example, if the credential has a structure, it is easier to perform a brute force attack. 3.3. Retry PIN No PIN retry counter has been implemented, but the key derivation function has been programmed to prevent brute force attacks. Eg, whenever a PIN is presented within the same session, it will work twice as slow; if in this case a normal PIN entry is 1 sec. lasts, will be the 10 th PIN entry last more than 10 minutes. A second embodiment of the present invention includes steps (1) memory box initialization, (2) application initialization initialization, and (3) use application credentials, as further described below: 1. Initialization memory box (see fig. 4) 1.1. Application in App Store An uninitialized memory box application contains the server public key, identified by Pu_S, and the server security module public key, identified by Pu_SM. BE2016 / 5324 Obfuscation is used to store and bind these public keys within the application software so that a hacker cannot easily replace them to build a rogue application. The server contains both the public key Pu_S and the associated private key Pr_S. The server security module contains both the public key Pu_SM and the associated private key Pr_SM. 1.2. Installation of the application in the device During personalization of the memory box application, a temporary key pair (public key Pu_A, private key Pr_A), a random r_A and r_DID, and a nonce nl are generated. The random r_DID is used by the memory box application to randomize the device ID (DID), resulting in the randomized device ID designated by DIDr. The user is asked to enter his profile including a valid storage identification SID (eg email address) and optionally a valid out-of-band identification OBID (eg mobile phone number). The user is prompted to select a PIN to be used as the KUC, and optionally an additional passphrase to be used as a more secure KUC. The memory box application extracts readable device information from the device. The protocol ID (PID) equal to 1, device information, randomized device_ID (DIDr), SID, OBID, r_A, PIN (encrypted under public key Pu_SM) and optional passphrase (encrypted under public key Pu_SM) are sent to the server, encrypted under public key Pu_S, verified with private key Pr_A and saled with nonce en. Nonce en and public key Pu_A are sent legibly to the server. The following assumes that only a PIN, and not a PIN and passphrase, is sent to the server. 1.3. Server-side decryption The server decrypts the information received from the memory box application and validates the received information (eg it checks if the PID is equal to 1). 1.4. Validation of user and device on server side BE2016 / 5324 The server validates the device identified by DIDr and checks that the user identified by the pair (SID, OBID) has permission to initialize a memory box application. 1.5. Generation of the user ID (UID) In the case of an existing user, the server obtains the associated UID. In the case of a new user, the server either generates a random UID or generates the UID using an OWF using the user's SID (e.g. email address) and the user's OBID (e.g. mobile phone number). 1.6. Dynamic key generation The server generates a random r_S and generates keys KO and Kl: KO is generated using an OWF using UID, DIDr, r_A and r_S Kl is generated using an OWF using PIN, UID, DIDr, r_A and r_S Protections are implemented to prevent dictionary attacks and brute force attacks, eg by implementing OWF as a time and optional memory consuming algorithm (eg a KDF). To prove to the memory box application that the server was able to correctly derive keys KO and Kl, it generates a MAC for r_A using both KO and Kl. This MAC is referred to as MAC_S. 1.7. Generation of the asymmetric client key pair and client certificate The server generates an asymmetric client key pair and the associated client certificate for a particular user and device, and bundles the key pair and certificate into a container file, identified by File_CI. The server also assigns the certificate serial number the value generated using an OWF using UID and DIDr. BE2016 / 5324 1.8. Transmission of UID, r_S, MAC_S and File_CI by the server The server generates a nonce n2 and prepares a data string containing UID, r_S XOR'ed (i.e. encrypted using a bitwise XOR operator) with r_A, MAC_S and File_CI. The server sends this data string to the memory box application, encrypted under Pu_A, verified with the private key Pr_S, salted with nonce n2. 1.9. Transmission of nonce n2 by the server The server can send nonce n2 readable to the memory box application. In case there is an out-of-band channel (eg SMS), the server can send the nonce n2 cryptographically modified with any verification code C_Auth, which is sent via this outof-band channel (eg SMS) . Sending C_Auth through another channel increases security, although it can still be intercepted by the network or a rogue application. However, it does have the advantage that it also brings additional confidence in identification because the user has entered a correct OBID (eg mobile phone number). 1.10. Verification of SID The server performs a process to verify that the SID is authentic and belongs to the user. In a preferred embodiment, the SID is an email address and this process takes the form of an authentication link sent via email to the user's email address. 1.11. Decryption on the application side The memory box application decrypts the information received from the server and validates the received information. 1.12. Generation of the dynamic keys by the memory box application The memory box application derives UID and r_S from the information received from the server. The memory box application generates the keys KO and Kl: KO is generated using an OWF using UID, DIDr, r_A and r_S Kl is generated using an OWF using PIN, UID, DIDr, r_A and r_S BE2016 / 5324 Obfuscation is used in the implementation of the OWF in the memory box application. To prove to the server that the memory box application was able to correctly derive keys KO and Kl, it generates a MAC for r_S using both KO and Kl. This MAC is referred to as MAC_A. 1.13. Transmission of MAC_A by the memory box application The memory box application generates a nonce n3. The PID equal to 1, UID, DIDr and MAC_A are sent to the server, encrypted under Pu_S, verified with the private key Pr_A, salted with nonce n3. Nonce n3 and public key Pu_A are sent to the server readable. 1.14. OBID verification The server decrypts the information received from the memory box application and validates the received information. The authentication of MAC_A not only assures the server of the proper derivation of keys KO and Kl by the application, but also verifies the user's OBID. 1.15. Storage and deletion by the memory box application The memory box application stores SID, UID, r_DID, r_A, and r_S, and initializes a counter at 0. Then, the memory box application installs the File_CI containing the client certificate. The memory box application removes OBID, PIN, DIDr, K0, Kl, Pu_A, Pr_A and nonces. 1.16. Storage and deletion by the server After checking the authentication link and the MAC_A, the server stores UID, DIDr, K0, Kl, device information, SID, OBID, and initializes a counter at 0. The server generates the keys KO and Kl using the security module. The server removes r_A, r_S and nonces. 1.17. One-time code generation by the server The server generates a one-time code for deregistering the OTDDC device and a set of one-time authentication codes OTACs and sends these one-time codes to the storage server associated with the user. The server stores these one-time codes as a content hash. B E2016 / 5324 2. Initialization of application credentials (see fig. 5) 2.1. preface The memory box application can be used by any third party application that wants to store credentials (passwords, keys, etc.) in an application, e.g. a mobile application, for offline and / or online applications. In most cases, these credentials will be initialized during installation, but of course this is not a must. To store credentials in the memory box, they must be available on the server side. The type of credential and how these credentials are generated or chosen is beyond the scope of the memory box concept. Here are some non-limiting options: An asymmetric key pair generated by a third-party application An authentication token generated by a third-party server A password entered in the device A symmetric key generated by a third-party application Such a given credential C is identified by the combination of the application identifier (AID) and the credential identifier (CID). The pair (AID, CID) that uniquely identifies the credential is generated by the third party application. Furthermore, the third-party application generates a credential storage identifier (CSID) for the particular credential C that includes how to store the credential (i.e. whether or not protected by the user's KUC) and whether the credential is specific to each device (e.g. an authentication token) or the same on all devices of the same user (e.g. a user's password). 2.2. Storage To store the credentials in the memory box, the following applies: BE2016 / 5324 a. The memory box application generates a temporary key pair (public key Pu_A, private key Pr_A), a random n_A and a nonce nl. b. The memory box application generates the randomized device ID DIDr from the device ID DID (extracted from the device) and the random r_DID (stored by the memory box application). c. Depending on the requested protection identified by CSID, the memory box application KO (not protected by the user's KUC) or K1 (protected by the user's KUC) derives from UID, DIDr, r_A and r_S, which were stored during initialization of the memory box for the particular UID (see step 1 and fig. 4). In the case of Kl, the user must enter a PIN. d. The memory box application increases the stored counter value by one and retrieves the updated value. e. The memory box application prepares a data string containing PID equal to 2, counter, UID, DIDr, AID, CID, CSID, n_A and C, encrypting C under the public key Pu_SM. The memory box application sends this data string to the server, encrypted under public key Pu_S, verified with the private key Pr_A, and saled with nonce ie. Nonce ni and public key Pu_A are sent to the server readable. The encrypted data also contains a Message Authentication Code (MAC) that uses either KO or Kl, depending on which key was derived in step c). The memory box application uses the client certificate to perform client authentication. f. The server decrypts the information received from the memory box application and validates the received information (eg it checks if the PID is equal to 2, checks if the counter is higher than the value stored, ...). The server updates the counter value. g. The server generates the universal ID of the credential (CUID) using an OWF using UID, AID, CID, and optionally DIDr if it is a device-specific credential. BE2016 / 5324 h. The server generates a random n_S and assigns the current time to the timestamp t_Stored, which indicates the time when the credential was stored (and is used as a version tracker of the credential). i. The server retrieves the stored KO or Kl using the pair (UID, DIDr) depending on the requested protection identified by CSID. j. The server encrypts the credential C using KO or Kl obtained in step i) salts with value n derived from n_A and n_S using an OWF. k. The server generates a nonce n2 and prepares a data string containing CUID, CSID, t_Stored, n_S and the encrypted credential encC. The server sends this data string to the memory box application, encrypted under private key Pu_A, verified with private key Pr_S, salted with nonce n2. Nonce n2 is readable sent to the memory box application. l. The backup data set containing CUID, CSID, t_Stored and n_A is sent to the storage server, eg in the form of an email to the email address corresponding to SID. The backup data series can be retrieved later from the storage server to ensure full recovery or initialization. m. The memory box application decrypts the information received from the server and validates the received information. The memory box application stores CUID, CSID, t_Stored, n_S and the encrypted credential encC in the memory box. n. The third party application stores CID, CUID, CSID, t_Stored and n_A in the third party application memory. o. The server stores UID, DIDr, AID, CID, CUID, CSID, t_Stored, n_S and the encrypted credential encC. p. In the case of a credential that is the same on all devices of the same user, the server can optionally push the encrypted credential to all devices registered under the same UID, using the associated KO or Kl associated with each device. BE2016 / 5324 3. Use application credentials (see fig. 6) 3.1. preface The memory box is a concept to store the credentials in a more secure way in the application, eg a mobile application. How these credentials are used is beyond the scope of this invention. It is up to the application developer to decide whether these credentials are used online and / or offline and whether they are used with or without the user's KUC (i.e. PIN). This section on the use of application credentials therefore only focuses on how to retrieve the credential offline in a readable manner. 3.2. to pick up To retrieve credentials identified with 3-tuple (CUID, CSID, t_Stored) stored in the memory box, apply the following: a. The third-party application retrieves CUID, CSID, t_Stored, and n_A using the credential identifier CID, and sends this data to the memory box application. b. The memory box application retrieves n_S and the associated encrypted credential encC using CUID, CSID and t_Stored. c. The memory box application generates the randomized device ID DIDr from the device ID DID (extracted from the device) and the random r_DID (stored by the memory box application). d. Depending on the requested protection identified by CSID, the memory box application KO or K1 derives from UID, DIDr, r_A and r_S, which were stored during initialization of the memory box for the particular UID (see step 1 and fig. 4). e. In the case of Kl, i.e. if encC is protected by the user's PIN, the user is asked to enter his PIN. The PIN cannot be verified in the device, but entering an incorrect PIN results in an incorrect credential being retrieved. It is up to the third party application to see how the user gets feedback. f. The memory box application decrypts the stored credential encC using KO or Kl obtained during step d) salts BE2016 / 5324 with a value n derived from n_A and n_S using an OWF. g. The decrypted credential C is returned legibly to the application of third parties. The application developer should be aware that certain precautions should be taken when defining the credential. For example, if the credential has a structure, it is easier to perform a brute force attack. Therefore, the credential should be as unstructured as possible and look as arbitrary as possible. Preferably, the credential is randomized in advance by the third party application before being saved. 3.3. Retry PIN In the memory box application, a PIN retry counter is not implemented, but the key derivation function (KDF) is programmed to prevent brute force attacks. For example, depending on the number of times a PIN is presented within a given time slider, it will work exponentially slow; in this case, if one PIN entry is 1 sec. takes, i takes the PIN input within the time-sliding window 2 (kl) sec. It is believed that the present invention is not limited to any form of embodiment previously described and that some modifications may be added to the present manufacturing example without revaluation of the appended claims. The invention is further described by the following non-limiting examples which further illustrate the invention, and are not intended, nor should be interpreted, to limit the scope of the invention. EXAMPLES Example 1: offline password A very simple use case for the memory box is the secure storage of an offline password. The procedure is simple: the credential takes the form of a password and is encrypted under KO. The application BE2016 / 5324 can always check the password offline by comparing the entered value with the encrypted value returned by the memory box application. If applicable, the server can distribute the credentials to other devices registered by the user. Example 2: Online transaction security using a symmetric key protected with a PIN A second use case is providing online transaction security. A symmetric key is generated in a third-party application. This key is stored under K1 by the memory box application. Whenever an online transaction needs to be verified, the user enters the PIN and the key can be retrieved. This key is then used to secure the transaction (eg to generate a MAC). If the PIN is entered incorrectly, the key will be retrieved incorrectly and the MAC will be incorrect. Example 3: Peer-to-peer transaction security using asymmetric key pair Another use case is securing peer-to-peer (P2P) transactions between two devices. During initialization of such a peer-to-peer application, an asymmetric key pair Pu, Pr is generated. Pu is stored under KO, while Pr is stored under Kl. A certificate for Pu is generated by the server and also stored under KO. Two devices can then use asymmetric key cryptography techniques to secure peer-to-peer transactions between two devices. The use of the secret keys requires correct entry of the PIN by the corresponding user. Example 4: distribution and use of vouchers A typical use case of the invention as a whole is the distribution and transfer of vouchers, such as meal vouchers, gift cards and coupons, through the following steps: A device on which the vouchers are stored begins with the generation and storage of an asymmetric key pair in the memory box (see example 3) BE2016 / 5324 Meal vouchers take the form of a certificate generated by the public key server The third-party application can use the memory box application to store the meal vouchers in the vault in such a way that they can be accessed but not easily be copied by the user who owns the device running that application Meal vouchers can be transferred from one of the mentioned applications to another application in an offline mode and securely, with the memory box application ensuring that copying is disabled Meal vouchers can then be used safely, eg at a POS of a Merchant or Restaurant Store, both online and offline. BE2016 / 5324
权利要求:
Claims (15) [1] CONCLUSIONS A computer-implemented method for the secure storage of credentials for offline use and copy-protected vault content, using a server and an application on a user's device, comprising the steps of: e) said server storing said credentials unable to decrypt said credentials itself; f) said application that stores encrypted credentials on said device, unable to decrypt said credentials without the help of a trusting third party application and / or said user; g) being able to distribute said credentials across different devices of said same user, using both said server and interaction of said user; h) said user provides backup data without credentials to said server to restore said credentials in case of loss of said device; where the method does not require a Secure Element, but is secured using cryptographic keys and encrypted storage. [2] A method for the secure storage of credentials for offline use and copy-protected vault content using a server and an application on a first device of a first user according to claim 1, wherein said copy-protected vault content is transferred from said first device of said first user to a second device of said first user and / or said copy-protected vault content is transferred from said first device of said first user to a third device of a second user, characterized in that said copy-protected vault content is transferred without connecting to said server. [3] The method of claims 1-2, wherein server-side credentials are reconstructed jointly by said server and said user of said application. B E2016 / 5324 [4] Method according to claims 1-3, wherein reconstruction of credentials on the application side takes place jointly by said application and said trusting application of third parties. [5] A method according to claims 1-4, wherein said user must additionally provide a Key Unlocking Code, said Key Unlocking Code protecting said credentials and said copy-protected vault content and said server and said application not storing said Key Unlocking Code of said user . [6] The method of claims 1-5, wherein an instance of said application is instantiated with one or more service-specific identities, which are checked by the service owner and allow to store vault content. [7] A method according to claims 1-6, wherein said service-specific identities are implemented with a service-specific Public Key Infrastructure (PKI). [8] The method of claims 1-7, wherein said vault content is transferred from one service-specific vault to another identified service-specific vault, without interaction from said server (i.e. offline). [9] The method of claims 1-8, wherein different types of said vault contents coexist within the same instance of said application, but are isolated from each other. [10] The method of claims 1-9, wherein said vault content is immediately deleted by the memory box application once it has been issued, transferred or spent and cannot be recovered (ie said server removes the content once it has been issued) and is securely stored in up to one of said service-specific safes to prevent copying. [11] The method of claims 1-10, wherein said vault content can be spent at a Point of Service (POS), wherein said device is offline and said POS is either offline or online. [12] The method of claims 1-11, wherein said service-specific vault supports or prevents duplication of said vault contents. B E2016 / 5324 [13] Method according to claims 1-12, wherein said methods, storage and services are implemented in the Secure Element of a device and / or the Secure Element of a smart card. [14] A system suitable for a computer-implemented method according to claims 1-13, comprising a processing unit configured to implement said computer-implemented method. [15] An application product suitable for a computer-implemented method according to claims 1-14, comprising at least one computer-accessible medium on which computer-accessible program code parts are 10, which include instructions for the implementation of said computer-implemented method. B E2016 / 5324
类似技术:
公开号 | 公开日 | 专利标题 EP2991267B1|2019-10-23|Apparatus for providing puf-based hardware otp and method for authenticating 2-factor using same US8059818B2|2011-11-15|Accessing protected data on network storage from multiple devices WO2013080204A1|2013-06-06|Methods and devices for securing keys for a non-secured, distributed environment with applications to virtualization and cloud-computing security and management CN107453880B|2020-02-28|Cloud data secure storage method and system US20210083872A1|2021-03-18|Systems, methods, and devices for secure blockchain transaction and subnetworks CN107920052B|2020-11-17|Encryption method and intelligent device TWI476629B|2015-03-11|Data security and security systems and methods US20200160333A1|2020-05-21|System and method for the protection of consumer financial data utilizing dynamic content shredding BE1024812A9|2018-07-26|A SECURITY APPROACH FOR THE STORAGE OF CREDENTIALS FOR OFFLINE USE AND AGAINST COPY PROTECTED CLEAN CONTENT IN DEVICES KR20210066867A|2021-06-07|An encrypted asset encryption key portion that allows assembly of an asset encryption key using a subset of the encrypted asset encryption key portion. Thilakanathan et al.2014|Secure multiparty data sharing in the cloud using hardware-based TPM devices WO2021129003A1|2021-07-01|Password management method and related device WO2020114377A1|2020-06-11|Secure distributed key management system Jang-Jaccard et al.2012|Portable key management service for cloud storage US10764260B2|2020-09-01|Distributed processing of a product on the basis of centrally encrypted stored data US10257176B2|2019-04-09|Replacing keys in a computer system Jain2017|Enhancing security in Tokenization using NGE for storage as a service US20220014367A1|2022-01-13|Decentralized computing systems and methods for performing actions using stored private data Chheda et al.2015|Public Auditing For The Shared Data In The Cloud KR20190002388A|2019-01-08|Puf-based hardware device for providing one time password, and method for 2-factor authenticating using thereof Hussain et al.2016|A smart card based security extension for the bitcoin wallets KR101947408B1|2019-02-13|Puf-based hardware device for providing one time password, and method for 2-factor authenticating using thereof Kowalski2018|CRYPTOBOX V2. Shah et al.2019|Third Party Public Auditing Scheme for Security in Cloud Storage JP2018026651A|2018-02-15|Method for protecting program
同族专利:
公开号 | 公开日 BE1024812A1|2018-07-04| BE1024812B1|2018-07-10| WO2016177843A1|2016-11-10| EP3292654B1|2019-08-14| BE1024812B9|2018-07-30| EP3292654A1|2018-03-14|
引用文献:
公开号 | 申请日 | 公开日 | 申请人 | 专利标题 KR100648064B1|2004-01-14|2006-11-23|주식회사 케이티프리텔|mobile terminal for certification, E-commerce system and method using the terminal| WO2009070430A2|2007-11-08|2009-06-04|Suridx, Inc.|Apparatus and methods for providing scalable, dynamic, individualized credential services using mobile telephones| US9390414B2|2011-09-18|2016-07-12|Google Inc.|One-click offline buying| US20140108793A1|2012-10-16|2014-04-17|Citrix Systems, Inc.|Controlling mobile device access to secure data|EP3530602B1|2018-02-23|2020-06-17|Otis Elevator Company|Safety circuit for an elevator system, device and method of updating such a safety circuit| TWI703851B|2019-07-30|2020-09-01|華東科技股份有限公司|Peer device connection method|
法律状态:
2018-09-05| FG| Patent granted|Effective date: 20180710 | 2021-03-19| MM| Lapsed because of non-payment of the annual fee|Effective date: 20200531 |
优先权:
[返回顶部]
申请号 | 申请日 | 专利标题 EP15166789|2015-05-07| EP15166789.6|2015-05-07| PCT/EP2016/060107|WO2016177843A1|2015-05-07|2016-05-04|A security approach for storing credentials for offline use and copy-protected vault content in devices| 相关专利
Sulfonates, polymers, resist compositions and patterning process
Washing machine
Washing machine
Device for fixture finishing and tension adjusting of membrane
Structure for Equipping Band in a Plane Cathode Ray Tube
Process for preparation of 7 alpha-carboxyl 9, 11-epoxy steroids and intermediates useful therein an
|